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Abstract — In  this  paper,  we  describe  a  reactive  robot 
architecture  that  uses  fast  re-planning  methods  to  avoid 
the  shortcomings  of  reactive  navigation,  such  as  getting 
stuck  in  box  canyons  or  in  front  of  small  openings. 
Our  robot  architecture  differs  from  others  in  that  it 
gives  planning  progressively  greater  control  of  the  robot 
if  reactive  navigation  continues  to  fail,  until  planning 
controls  the  robot  directly.  Our  first  experiments  on  a 
Nomad  robot  and  in  simulation  demonstrate  that  our 
robot  architecture  promises  to  simplify  the  programming 
of  reactive  robot  architectures  greatly  and  results  in 
robust  navigation,  smooth  trajectories,  and  reasonably 
good  navigation  performance. 

I.  Introduction 

Reactive  navigation  approaches  are  often  used  for 
robot  navigation  since  they  are  fast  and  rely  only  on 
the  current  sensor  readings  instead  of  an  accurate  map, 
the  use  of  which  requires  very  accurate  localization  ca¬ 
pabilities  [Arkin98].  However,  reactive  navigation  does 
not  plan  ahead  and  is  therefore  susceptible  to  local 
minima.  For  example,  it  can  get  stuck  in  box  canyons 
or  in  front  of  small  openings.  These  shortcomings  are 
usually  addressed  by  changing  from  one  behavior  to 
another  in  the  reactive  controller.  The  decision  when  to 
activate  which  behavior  can  be  made  either  1)  before 
or  2)  during  execution. 

1)  In  the  first  case,  a  programmer  creates  several 
behaviors,  each  of  which  is  suited  for  a  specific 
navigation  scenario  that  the  robot  might  get 
exposed  to,  for  example  one  behavior  for  naviga¬ 
tion  in  corridors  and  another  one  for  navigation 
in  forest.  Then,  the  programmer  encodes  when  to 
activate  which  behavior,  for  example,  in  form  of 
a  finite  state  automaton  whose  states  correspond 
to  behaviors  and  whose  transitions  correspond  to 
observations  made  during  execution.  This  finite 
state  automaton  corresponds  to  a  conditional  off¬ 
line  plan.  An  advantage  of  this  scheme  is  that 
it  results  in  good  navigation  performance  if  the 
programmer  anticipated  all  navigation  scenarios 
correctly.  A  disadvantage  is  that  the  rough  char¬ 
acteristics  of  the  terrain  need  to  be  known.  Also, 
the  finite  state  automaton  is  terrain  specific  and 
can  contain  a  large  number  of  behaviors,  which 


makes  its  programming  time-consuming.  The 
resulting  navigation  performance  can  be  poor  if 
the  programmer  did  not  anticipate  all  navigation 
scenarios  correctly.  Some  schemes  replace  the 
programmer  with  an  off-line  learning  method,  re¬ 
sulting  in  similar  advantages  and  disadvantages. 

2)  In  the  second  case,  the  reactive  controller  uses 
only  one  behavior,  but  an  on-line  planner  or 
learning  method  modifies  the  parameter  values 
of  the  behavior  during  execution,  for  example, 
when  the  robot  does  not  appear  to  make  progress 
toward  the  goal.  An  advantage  of  this  scheme  is 
that  it  can  be  used  even  in  the  presence  of  some 
simple  navigation  scenarios  that  the  programmer 
did  not  anticipate.  A  disadvantage  is  that  it  can 
result  in  poor  navigation  performance  for  some 
navigation  scenarios  since  the  reactive  controller 
needs  time  to  both  detect  when  the  parameters 
should  be  changed  and  experiment  with  how  to 
change  them. 

In  practice,  one  often  uses  a  combination  of  both 
schemes,  namely  the  first  scheme  for  high-level  terrain 
characteristics,  that  are  often  known  in  advance  (for 
example,  navigating  through  a  forest),  and  the  second 
scheme  for  low-level  terrain  characteristics,  that  are 
often  not  known  in  advance  (for  example,  getting  out 
of  box  canyons).  The  resulting  navigation  performance 
is  good  but  programming  is  difficult  since  one  has 
to  choose  behaviors,  sequence  them,  and  determine 
a  large  number  of  parameters  in  the  process.  We 
therefore  explore  an  alternative  scheme  that  utilizes 
on-line  planning  but  whose  reactive  controller  uses 
only  one  behavior  without  modifying  the  parameters  of 
the  behavior  during  execution.  Our  robot  architecture 
requires  only  a  small  amount  of  programming  (and 
testing)  since  one  does  not  have  to  choose  behaviors 
and  sequence  them.  One  only  needs  to  determine  a 
small  number  of  parameters. 

Combining  planning  and  reactive  navigation  is  not 
new.  Many  robot  architectures  use  on-line  planning 
to  determine  a  nominal  robot  trajectory  that  reactive 
navigation  has  to  follow.  In  this  case,  reactive  nav- 
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igation  enables  the  robot  to  move  around  obstacles 
that  planning  did  not  know  about  or  did  not  want  to 
model.  We,  on  the  other  hand,  use  on-line  planning 
in  a  different  way,  namely  to  help  reactive  navigation 
in  navigation  scenarios  where  it  is  unable  to  make 
progress  toward  the  goal.  Our  robot  architecture  differs 
from  other  robot  architectures  that  use  on-line  planning 
in  this  way  in  that  it  gives  the  planner  progressively 
greater  control  of  the  robot  if  reactive  navigation 
continues  to  fail,  until  on-line  planning  controls  the 
robot  directly.  The  amount  of  planning  and  how  closely 
the  planner  controls  the  robot  depend  therefore  on  the 
difficulty  that  reactive  navigation  has  with  the  terrain. 

The  primary  difficulty  with  implementing  our  robot 
architecture,  and  perhaps  the  reason  why  it  is  unusual 
to  let  on-line  planning  control  robots  directly,  is  that 
robot  architectures  need  to  plan  on-line  to  be  respon¬ 
sive  to  the  current  navigation  scenario.  Although  com¬ 
puters  are  getting  faster  and  faster,  on-line  planning 
is  still  slower  than  reactive  navigation  since  it  needs 
to  repeatedly  sense,  update  a  map,  and  adapt  its  plans 
to  changes  in  the  map.  Our  robot  architecture  address 
this  issue  by  determining  the  navigation  mode  in  a 
principled  way  so  that  the  time  during  which  planning 
controls  the  robot  directly  is  no  larger  than  necessary 
and  by  using  fast  replanning  methods  that  do  not  plan 
from  scratch  but  rather  adapt  the  previous  plan  to  the 
new  situation. 

II.  Our  Robot  Architecture 

Our  robot  architecture  is  a  three-layered  architecture 
with  a  reactive  layer  (that  implements  reactive  nav¬ 
igation),  sequencing  layer  (that  determines  the  navi¬ 
gation  mode),  and  deliberative  layer  (that  implements 
the  planner).  The  reactive  and  sequencing  layers  run 
continuously  but  the  deliberative  layer  runs  only  in 
certain  navigation  modes. 

A.  Reactive  Layer 

The  reactive  layer  uses  motor  schemata  [Arkin89]  to 
move  the  robot  to  given  coordinates  and  implements 
a  behavior  that  consists  of  two  primitive  behaviors, 
namely  moving  to  the  goal  and  avoiding  the  obstacles. 
Each  of  the  primitive  behaviors  generates  a  vector.  The 
reactive  layer  then  calculates  the  weighted  sum  of  the 
vectors  for  given  weights  that  do  not  change  during 
execution.  It  then  moves  the  robot  in  the  direction  of 
the  resulting  vector  with  a  speed  that  corresponds  to 
its  length. 

B.  Deliberative  Layer 

The  deliberative  layer  obtains  sensor  readings  from 
the  on-board  sensors,  updates  a  short-term  map  (oc¬ 
cupancy  grid),  and  then  uses  D*  Lite  [Koen02],  a 


simplified  and  thus  easy  to  understand  version  of  D* 
[Sten95a],  to  plan  a  path  from  the  current  location  of 
the  robot  to  the  goal  under  the  assumption  that  terrain 
is  easily  traversable  unless  the  map  says  otherwise. 

C.  Sequencing  Layer 

The  sequencing  layer  monitors  the  progress  of  the 
robot  and  determines  the  navigation  mode.  Our  robot 
architecture  uses  reactive  navigation  as  much  as  possi¬ 
ble  because  of  its  speed.  However,  reactive  navigation 
can  get  stuck  in  box  canyons  or  in  front  of  small  open¬ 
ings.  If  the  robot  does  not  make  progress  toward  the 
goal,  the  robot  architecture  activates  the  planner,  which 
sets  a  way-point  for  reactive  navigation  to  achieve, 
as  has  been  done  before  [Wett01][Urms03].  Reactive 
navigation  can  still  get  stuck  if  the  reactive  layer  is 
unable  to  reach  the  way-point.  For  example,  it  can  still 
get  stuck  in  front  of  small  openings.  If  the  robot  does 
not  make  progress  toward  the  next  way -point,  our  robot 
architecture  bypasses  reactive  navigation  completely 
and  lets  the  planner  control  the  robot  directly,  which 
is  rather  unusual  in  robotics.  Our  robot  architecture 
thus  operates  in  three  different  navigation  modes.  In 
mode  1,  reactive  navigation  controls  the  robot  and 
attempts  to  move  it  to  the  goal.  In  mode  2,  reactive 
navigation  controls  the  robot  and  attempts  to  move  it 
to  the  way-point  provided  by  the  planner.  In  mode  3, 
the  planner  directly  controls  the  robot  and  attempts  to 
move  it  to  the  goal.  Since  planning  is  much  slower  than 
reactive  navigation,  our  robot  architecture  always  uses 
the  smallest  navigation  mode  that  promises  to  allow 
the  robot  to  make  progress  towards  the  goal. 

We  now  describe  how  the  sequencing  layer  deter¬ 
mines  the  navigation  mode  with  only  two  parameters, 
called  PERSISTENCE  and  ANGLE  DEVIATION. 

•  The  mode  switches  from  1  to  2  when  the  robot 
travels  less  than  a  given  distance  during  the  time 
given  by  PERSISTENCE,  and  thus  appears  not 
to  make  progress.  In  mode  2,  the  planner  plans  a 
path  and  then  returns  as  way-point  the  point  on 
the  path  farthest  away  from  the  current  location 
of  the  robot  that  is  not  occluded  from  it  by  known 
obstacles.  This  way,  reactive  navigation  will  likely 
be  able  to  reach  the  way-point  but  still  has  control 
of  the  robot  for  a  long  time.  The  mode  switches 
from  2  back  to  1  when  the  difference  in  the 
movement  direction  recommended  by  mode  1  and 
the  direction  of  the  path  generated  by  the  planner 
is  less  than  ANGLE  DEVIATION  for  the  amount 
of  time  given  by  PERSISTENCE.  This  condition 
guarantees  that  the  robot  continues  to  move  in  the 
same  direction  after  the  mode  switch  that  it  was 
moving  in  before  the  mode  switch. 


Fig.  1.  Nomad  Robot  During  an  Experiment 


•  The  mode  switches  from  2  to  3  when  the  robot 
travels  less  than  a  given  distance  during  the 
time  where  the  planner  has  returned  the  same 
way-point  PERSISTENCE  number  of  times  or 
the  difference  in  the  movement  direction  recom¬ 
mended  by  mode  2  and  the  direction  of  the  way- 
point  set  by  the  planner  is  greater  than  ANGLE 
DEVIATION  for  the  amount  of  time  given  by 
PERSISTENCE.  (A  switch  from  mode  2  to  3 
takes  precedence  over  a  switch  from  mode  2  to 
1  in  case  both  conditions  are  satisfied.)  In  mode 
3,  the  planner  controls  the  robot  directly.  It  plans 
a  path  and  then  moves  the  robot  along  that  path 
for  a  distance  of  two  grid  cells  before  it  re-plans 
the  path.  This  short  distance  ensures  that  the  robot 
does  not  run  into  unknown  obstacles.  The  mode 
switches  from  3  back  to  2  when  the  difference  in 
the  movement  direction  recommended  by  mode  2 
(with  a  way-point  set  two  grid  cells  away  from  the 
current  cell  of  the  robot  on  the  planned  path)  and 
the  direction  of  the  path  generated  by  the  planner 
is  less  than  ANGLE  DEVIATION  for  the  amount 
of  time  given  by  PERSISTENCE.  This  condition 
guarantees  that  the  robot  continues  to  move  in  the 
same  direction  after  the  mode  switch  that  it  was 
moving  in  before  the  mode  switch. 

III.  Case  Study:  MissionLab 

To  demonstrate  the  advantages  of  our  robot  archi¬ 
tecture,  we  performed  a  case  study  with  MissionLab 
[Mlab02],  a  robot  programming  environment  that  has 
a  user-friendly  graphical  user  interface  and  implements 
the  AuRA  architecture  [Arkin97].  To  this  end,  we 
integrated  our  robot  architecture  into  MissionLab.  All 
experiments  were  performed  either  in  simulation  or  on 
a  Nomad  150  with  two  SICK  lasers  that  provide  a 
360  degree  field  of  view,  as  shown  in  Figure  1.  There 
was  neither  sensor  nor  dead-reckoning  uncertainty  in 


Fig.  2.  Simulation  Experiment  1  -  MissionLab 


simulation  but  a  large  amount  of  both  sensor  and  dead¬ 
reckoning  uncertainty  on  the  Nomad.  The  Nomad  used 
no  sensors  other  than  the  lasers  and  no  localization 
technique  other  than  simple  dead-reckoning  (where 
walls  were  used  to  correct  the  orientation  of  the 
robot).  We  limited  its  speed  to  about  30  centimeters 
per  second  to  reduce  dead-reckoning  errors  due  to 
slippage.  MissionLab  was  run  on  a  laptop  that  was 
mounted  on  top  of  the  Nomad  and  connected  to  the 
lasers  and  the  Nomad  via  serial  ports. 

A.  Simulation  Experiments 

We  first  evaluated  our  robot  architecture  in  simula¬ 
tion  against  MissionLab,  that  fits  the  first  scheme  men¬ 
tioned  in  the  introduction,  where  the  decision  when 
to  activate  which  behavior  is  made  before  execution. 
Thus,  we  assume  that  a  map  of  the  terrain  is  available. 
The  robot  starts  in  a  field  sparsely  populated  with 
obstacles,  has  to  traverse  the  field,  enter  a  building 
through  a  door,  travel  down  a  corridor,  enter  a  room 
and  move  to  a  location  in  the  room,  as  shown  in 
Figure  2. 

A  programmer  of  MissionLab  first  creates  several 
behaviors  with  and  then  a  finite  state  automaton  that 
sequences  them.  Figure  3  shows  a  way  of  solving 
the  navigation  problem  with  MissionLab  that  needs 
eight  different  behaviors  with  a  total  of  32  parameters 
in  the  finite  state  automaton  to  accomplish  this  task. 
For  example,  the  behavior  for  moving  in  corridors 
uses  a  wall-following  method  with  six  parameters. 
We  optimized  the  behaviors,  their  sequence,  and  the 
parameter  values  to  yield  a  small  travel  time.  Figure  2 


Fig.  3.  Finite  State  Automaton  for  MissionLab 


Fig.  4.  Simulation  Experiment  1  -  Our  Robot  Architecture 


shows  the  resulting  trajectory  of  the  robot.  The  total 
travel  time  is  16.1  seconds.  (All  times  include  the  start¬ 
up  times  of  MissionLab). 

Our  robot  architecture  uses  only  one  behavior  with 
four  parameters  plus  two  parameters  to  switch  navi¬ 
gation  modes.  Consequently,  it  requires  only  a  small 
amount  of  programming  (and  testing)  since  one  does 
not  have  to  choose  behaviors  and  sequence  them 
but  only  needs  to  set  six  parameter  values.  Figure  5 
shows  the  time  that  the  robot  spent  in  mode  3  and 
the  travel  time  of  the  robot  for  different  values  of 
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Fig.  5.  Effect  of  Variation  of  Parameter  Values 


PERSISTENCE  and  ANGLE  DEVIATION.  If  AN¬ 
GLE  DEVIATION  is  too  large,  then  the  robot  does 
not  complete  its  mission  and  these  times  are  infinity. 
Notice  that  the  travel  time  first  decreases  and  then 
increases  again,  as  ANGLE  DEVIATION  increases  for 
a  given  PERSISTENCE.  This  systematic  variation  can 
be  exploited  to  find  good  values  for  the  two  parameters 
with  a  small  number  of  experiments.  The  travel  time  is 
minimized  if  PERSISTENCE  is  2  and  ANGLE  DEVI¬ 
ATION  is  5.  Figure  4  shows  the  trajectory  of  the  robot 
for  these  parameter  values.  The  robot  started  in  mode 
1,  entered  mode  2  at  point  A,  mode  3  at  point  B,  mode 
2  at  Point  C,  mode  3  at  Point  D,  and  mode  2  at  point 
E.  The  total  travel  time  of  the  robot  was  25.5  seconds, 
which  is  larger  than  then  total  travel  time  of  the  robot 
under  MissionLab,  as  expected  since  we  spent  a  long 
time  tuning  MissionLab,  but  still  reasonable.  Note  that 
the  parameter  values  of  the  controller  prevent  it  from 
entering  the  room  that  contains  the  goal.  Therefore, 


Fig.  6.  Simulation  Experiment  2 


(a)  Learning  Momentum 


(b)  Avoiding  the  Past 


(c)  Our  Robot  Architecture 


Fig.  7.  Simulation  Experiment  3 


our  robot  architecture  eventually  switches  into  mode 
3  and  lets  the  planner  control  the  robot.  Thus,  it  is 
able  to  correct  poor  navigation  performance  caused  by 
parameter  values  that  are  suboptimal  for  the  current 
navigation  situation. 

We  now  evaluate  our  robot  architecture  in  simulation 
against  other  techniques  that  can  be  used  to  overcome 
poor  navigation  performance  but  do  not  use  on-line 
planning,  biasing  the  robot  away  from  recently  visited 
locations  (called  “avoiding  the  past”)  [Balch93]  and 
adjusting  the  parameter  values  of  behaviors  during  ex¬ 
ecution  (called  “learning  momentum”)  [LeeOl].  These 
techniques  fit  the  second  scheme  mentioned  in  the  in¬ 
troduction,  namely  where  the  decision  when  to  activate 
which  behavior  is  made  during  execution.  Thus,  we 
assume  that  a  map  of  the  terrain  is  not  available.  Differ¬ 
ent  from  our  robot  architecture,  these  schemes  are  only 
designed  to  be  used  for  simple  navigation  scenarios, 
such  as  box  canyons  and  small  openings,  and  not  to 
relieve  one  from  choosing  behaviors,  sequencing  them, 
and  determining  their  parameter  values  for  complex 
navigation  tasks  such  as  the  one  discussed  above.  For 
each  experiment,  we  chose  the  same  parameter  values 
for  the  reactive  controller  (taken  from  the  MissionLab 
demo  files)  and  optimized  the  remaining  parameter 
values  of  each  technique  to  yield  a  small  travel  time.  In 
fact,  learning  momentum  required  the  parameter  values 
to  be  tuned  very  carefully  to  be  successful. 

•  In  the  first  experiment,  the  robot  operated  ten 
times  in  a  terrain  with  a  box  canyon,  as  shown 
in  Figure  6.  Our  robot  architecture  succeeded  in 
all  ten  runs,  invoked  the  planner  only  twice  per 
run,  and  needed  an  average  travel  time  of  13.9 
seconds.  Avoiding  the  past  and  the  ballooning 


version  of  learning  momentum  also  succeeded, 
with  average  travel  times  of  9.8  and  26.1  seconds, 
respectively. 

•  In  the  second  experiment,  the  robot  operated  ten 
times  in  a  terrain  with  a  small  opening,  as  shown 
in  Figure  7.  Our  robot  architecture  succeeded  in 
all  ten  runs  and  needed  an  average  travel  time  of 
4.7  seconds.  Avoiding  the  past  and  the  squeezing 
version  of  learning  momentum  also  succeeded, 
with  average  travel  times  of  4.3  and  2.8  seconds, 
respectively. 

Note  the  smoothness  of  the  trajectory  in  both  exper¬ 
iments  when  using  our  robot  architecture  compared  to 
avoiding  the  past  and  learning  momentum. 

B.  Robot  Experiments 

We  now  evaluate  our  robot  architecture  on  the 
Nomad  robot.  We  used  the  same  parameter  values  for 
both  experiments. 

•  In  the  first  experiment,  the  robot  operated  in 
a  corridor  environment,  as  shown  in  Figure  8 
together  with  resulting  trajectory  of  the  robot. 
(This  map  was  not  generated  by  the  robot  but  was 
constructed  from  data  obtained  during  the  trial. 
Since  the  robot  used  only  simple  dead-reckoning, 
its  short-term  map  deteriorated  over  time  and  was 
discarded  whenever  the  goal  became  unreachable 
due  to  dead-reckoning  errors.)  The  robot  had  to 
navigate  about  20  meters  from  our  lab  via  the 
corridor  to  the  mail  room.  The  robot  started  in 
mode  1,  entered  mode  2  at  point  A,  mode  3  at 
point  C,  mode  2  at  point  D,  mode  1  at  point  F, 
mode  2  at  point  G,  and  finally  mode  1  at  point 
H.  The  other  points  mark  additional  locations  at 


Fig.  8.  Robot  Experiment  1  (Grid  Cell  Size  10x10  cm) 


Fig.  9.  Robot  Experiment  2  (Grid  Cell  Size  15x15  cm) 


which  the  planner  was  invoked  in  mode  2  to  set 
a  way-point. 

•  In  the  second  experiment,  the  robot  operated  in 
an  open  space  that  was  sparse  populated  with 
obstacles,  as  shown  in  Figure  9  together  with  the 
trajectory  of  the  robot.  The  robot  had  to  navigate 
about  28  meters  in  the  foyer  of  our  building, 
through  a  sparse  field  of  obstacles  past  a  box 
canyon  to  the  goal,  as  shown  in  Figure  1.  The 
robot  started  in  mode  1,  and  entered  mode  2  at 
point  A.  Point  B  and  C  mark  additional  locations 
at  which  the  planner  was  invoked  in  mode  2  to 
set  a  way-point. 

These  experiments  demonstrate  that  the  amount  of 
planning  performed  by  our  robot  architecture  and  how 
closely  the  planner  controls  the  robot  depend  on  the 
difficulty  that  reactive  navigation  has  with  the  terrain. 
The  planner  is  invoked  only  if  necessary.  For  example, 
mode  1  is  used  throughout  the  easy-to-traverse  corridor 
in  the  first  experiment.  Mode  3  is  invoked  only  close  to 
the  narrow  doorway  but  not  the  wider  one  in  the  first 
experiment  and  not  at  all  in  the  second  experiment. 

IV.  Related  Work 

Our  robot  architecture  is  a  three-layered  architecture 
with  a  powerful  deliberative  layer  and  a  degenerated 
sequencing  layer,  whereas  many  three-tiered  archi¬ 
tectures  fit  the  first  case  described  in  the  introduc¬ 
tion  and  have  a  degenerated  deliberative  layer  but  a 
powerful  sequencing  layer,  for  example,  one  based 
on  RAPS  [Firby87].  The  planners  of  some  of  these 
robot  architectures  run  asynchronously  with  the  control 
loop  [Gat91],  whereas  the  planners  of  others  run  syn¬ 
chronously  with  the  control  loop  [Bon97].  Similarly, 


the  planners  of  some  of  these  robot  architectures  run 
continuously  [Sten95]  [Lyons95],  whereas  the  planners 
of  others  run  only  from  time  to  time  [Bon97].  The 
planner  of  our  robot  architecture  runs  synchronously 
with  the  control  loop  and,  depending  on  the  navigation 
mode,  either  continuously  (to  control  the  robot  in  mode 
3)  or  only  from  time  to  time  (to  plan  the  next  way-point 
in  mode  2).  It  differs  from  the  planners  of  other  robot 
architectures  in  that  it  can  control  the  robot  directly, 
when  needed.  This  is  a  radical  departure  from  the 
current  thinking  that  this  should  be  avoided  [Gat98] 
and  the  suggestion  to  use  plans  only  as  advice  but 
not  commands  [Agre90]  which  is  based  on  experience 
with  classical  planning  technology  that  was  too  slow 
for  researchers  to  integrate  it  successfully  into  the 
control  loop  of  robots  [Fikes71].  Our  robot  architecture 
demonstrates  that  using  plans  sometimes  as  advice 
(mode  2)  and  sometimes  as  commands  (mode  3), 
depending  on  the  difficulty  that  reactive  navigation  has 
with  the  terrain,  can  result  in  robust  navigation  without 
the  need  for  encoding  world  knowledge  in  the  robot 
architecture. 

V.  Conclusions 

We  described  a  reactive  robot  architecture  that  uses 
fast  re-planning  methods  to  avoid  the  shortcomings 
of  reactive  navigation,  such  as  getting  stuck  in  box 
canyons  or  in  front  of  small  openings.  Our  robot  ar¬ 
chitecture  differs  from  other  robot  architectures  in  that 
it  gives  planning  progressively  greater  control  of  the 
robot  if  reactive  navigation  continues  to  fail  to  make 
progress  toward  the  goal,  until  planning  controls  the 
robot  directly.  To  the  best  of  our  knowledge,  our  robot 
architecture  is  the  first  one  with  this  property.  It  also 
requires  only  a  small  amount  of  programming  (and 
testing)  since  one  does  not  have  to  choose  behaviors 
and  sequence  them.  One  only  needs  to  determine  a 
small  number  of  parameters.  Our  first  experiments  on 
a  Nomad  robot  and  in  simulation  demonstrated  that  it 
results  in  robust  navigation,  relatively  smooth  trajecto¬ 
ries,  and  reasonably  good  navigation  performance.  It  is 
therefore  a  first  step  towards  integrating  planning  more 
tightly  into  the  control-loop  of  mobile  robots.  In  future 
work,  we  intend  to  increase  the  navigation  performance 
of  our  robot  architecture  even  further.  We  also  intend  to 
explore  how  to  use  on-line  learning  and,  if  available,  an 
a-priori  map  to  automatically  determine  the  parameter 
values  of  our  robot  architecture  to  enable  it  to  operate 
in  any  kind  of  terrain  without  a  programmer  having  to 
modify  them. 
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